Subject: Flow Control SIG Status

From: "Shannon Nix" <[email-masked]>
Date: Thu, 12 Aug 93 09:53:20 EST

FC Siggers,

The AIW is rapidly approaching.  Per our timeline, we were to have a
"rough concensus proposal" based on all submitted proposals last Friday.
Given that:

   1) Peter's proposal was the only complete proposal submitted AND...
   2) Seems to be a fairly robust starting point...

I propose using Peter's proposal as a base-line for our work.  

We are scheduled to submit a draft proposal to the AIW by Aug 27.

Based on our conversations, I have put together a set of contentious issues 
that need to be addressed before we present this draft to the AIW.  I 
would like to get as much input as possible on each of these issues.  
Please provide supporting dialogue with your preferences.  Of course, if I 
have omitted issues or you have alternate proposals, please let met know.  

Note: I will only provide a brief outline for each issue.  Please take the
      time to review the previous dialogues before "casting your votes"

1.  BUFFER ALLOCATION

Baseline proposal: Peter Gayek

                   No requirement to preallocate buffers for 
                   all outstanding windows.  Statistical allocation
                   shall be permitted.  NOTE: This does not preclude
                   a preallocation scheme.  

                   Peter: do you have a statistical algorithm in mind?
                   If so, perhaps this should be included in the proposal 
                   if we choose to go down this path.

Alternate proposal: Shannon Nix
                   Maintaining "optimal window sizes" which may 
                   statistically overcommit the system buffercapacity.  
                   BUT.. not allowing outstanding windows to overcommit 
                   the system buffer capacity.

2. PACING RESPONSES

There are really two issues here:

      1. Preventing Deadlock
      2. Performance

Does any one disagree that Peter's proposal to restrict pacing responses
from being piggy-backed on user data elimates the dead-lock problem?

The second issue is that if Independent Pacing Responses (IPRs) flow on the
same channel as user data, then performance will suffer.

Proposal in one of Peter's appends:

       Use URGENT data flows for IPRs.  Andy countered that in some (all?)
       implementations, the receiving application will only be made aware
       that urgent data is queued, but must still process all previously
       queued user data on that stream first.  Correct me if I've mis-stated
       this, Andy.  Another question: wouldn't there be some advantage 
       gained on the sending side?

Andy's proposal:

       Have an out-of-band channel in each direction for control messages.
       The problem here is that we would then require two full-duplex 
       transport connections ( 6611 is currently using two in simplex mode).
       This would eliminate any change of halving the scalability problem.

SINGLE/DOUBLE/MULTIPLE TRANSPORT CONNECTIONS (TCs)

There are two opposing forces here:

       1. Increased function (and simplicity??) afforded by more TCs
            VS
       2. System resources and configuration to support more TCs

It is already acknowledged that we have a serious scalability problem with
a full mesh, single TC network so I believe every effort should be made
to restrict the number of TCs required.  However there are a number of 
reasons why multiple TCs might be desirable:

1.  The current 6611 implementation expects two. So the minimum proposal 
    would be to start with two (simlex) and negotiate to one (duplex) during
    capabilities exchange.

2.  Support of two (duplex) TCs would be required to support Andy's proposal
    above.  This may be the only acceptable means of getting IPRs back
    in a timely fashion.

3.  Support of an arbitrary negotiable number of TCs: N wher N>=1 would 
    afford load-balancing.  To really benifit from this feature, however,
    I think there is a "large can of worms" waiting on us.  It is
    my opinion that this should be deferred until after our initial work
    is complete.

4.  Support of one TC per circuit.  It has been suggested that this would
    simplify our problems.  I not sure that I, personally, accept that 
    argument.  However, I believe that resource limitations make this 
    proposal impractical.

USE OR NON-USE OF A "RESET" MECHANISM TO RESPOND QUICKLY TO BOUNDARY 
BACK-PRESSURE

Baseline proposal:  Peter

      Defines a RESET/RESET ACK mechanism on a per circuit basis to
      respond quickly to boundary back-pressure (RNRs).  Further defines
      a RESET mechanism on a TC basis to respond to system congestion (
      requirement for the latter is tied more to our choice of buffer 
      allocation schemes).

Alternate proposal:  Shannon

      Circuit reset is unnecessary if fair ( per circuit) end-to-end 
      buffer allotment and flow control mechanisms are implemented.  Further
      use of this mechanism could be detrimental to performance in some 
      cases are enforced.

      TC RESET has utility ONLY if we allow statistical buffer allocation 
      so that one may quickly shut a TC down to respond to local congestion.

HANDLING OF CONNECTIONLESS TRAFFIC

Issue:  There is no mechanism to "push-back" on the end-stations at the
        boundary of the network.  So there is no way to enforce end-to-end
        flow control for connectionless traffic.  This is OK ( sort of) 
        since, by definition, delivery of CL traffic is not guaranteed and,
        therefore, may be discarded.  The issue is: Where does the traffic
        get discarded?

Baseline proposal:  Peter

      Connectionless traffic is not subject to flow control and should
      be discarded at the point of congestion if congestion occurs.

Alternate proposal: Shannon
      Connectionless traffic is subject to the same flow control across the
      network (SSP) and should be discarded at the originating boundary
      if traffic arrives at a greater rate than the flow contol will allow.

NEGOTIATION OF THE INITIAL PACING WINDOW SIZE

Baseline proposal : Peter

    This is a marginally-nice-to-have that is not worth the effort to
    implement for our initial work.  Let's default it to one or two.

Alternate proposal : Shannon

    Default to one or two BUT allow negotiation of other default sizes
    in the capabilities exchange.  It is really up to the receiver to
    tell the sender what his default is.

INTEROPERABILITY WITH CURRENT 6611 IMPLEMENATION!!!

I have not seen this addressed yet.  We should describe a mechanism whereby
our implementations can interoperate with current 6611s in the field
( I assume this is a goal???).  Whatever this is, it would seem to involve
the capabilities exchange process.

OTHER ISSUES???

Rgds, Shannon
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)(*)   Shannon Nix    (*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)      Netlink, Inc.     (*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  3214 Spring Forest Rd.   (*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  Raleigh N.C. 27604 USA   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Phone:  (919)-878-8612   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Fax:    (919)-872-2132   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*) Internet: [email-masked] (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)

---

From: [email-masked] (Anand Subramaniam)
Date: Thu, 12 Aug 93 16:20:52 PDT

>        gained on the sending side?

		You are correct.  In TCP there are  2 things we must realyy rely upon
		because of so many varied implementations.

		1.	URGENT DATA. We might have an urgent pointer stuck somewhere down
		the receive data pipe and the user does not have  buffers to read
		data. So This could result in deadlock.

		2.	Connection release: Connections could be released in 2 ways.

			a). Orderly release: This will ensure that all the data that has
			been transmitted earlier is delivered to the remote user. This is
			bi-directional. The receiver if he has nothing more to send can
			activate orderly release and this will ensure that every drop of
			data is delivered properly. NOT ALL IMPLEMENTATIONS SUPPORT THIS!

			b).	Abortive release: This is the regular disconnect. This means
			that the the data that is on the send pipe/ receive pipe could
			get flushed so ALL of the data might not be delivered to the
			user. The DLSw must be able to handle this.
>     argument.  However, I believe that resource limitations make this 

	 Again as far as resource limitations goes, this is very subjective. If
	 the TCP send window is full, the DLSw need not queue any more on its
	 send queue and could instruct the LAN side to stop sending data with
	 RNR. The only difference here is that instead of having "windows' and
	 storing it on the DLSw, we will be storing it on the TCP send queue. The
	 worst case being 1 more buffer on the DLSw send queue. The idea is that
	 we are transferring the window responsibility to the TCP instead of
	 DLSw. 

Regards,

--andy
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UUCP:  {ames,apple,sun,mtxinu}!excelan!andy         (Anand Subramaniam) |
| INTERNET:  [email-masked]                          Ph : (408)-473-8413 |
| " Now and then I go off in to my own little world; But they know me     |
|   there"                                                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: [email-masked] (Anand Subramaniam)
Date: Thu, 12 Aug 93 17:08:27 PDT

>         You are correct.  In TCP there are  2 things we must NOT really rely 
	upon  because of so many varied implementations.       ^^^

	Sorry. A typo. It must be  a NOT.
--